Thanks.

This is probably good and we can land it. But I suspect that this spot being so hot may be the symptom of a different performance problem, and fixing that would yield an even bigger win.

I've had reports that suggest that the PackageCache is getting cache misses when we wouldn't expect it to. If you'd like to check for that in your app, see how many times Package is constructed for the same root. We'd expect a small number (maybe two per OS-level process). The constructor is here.

That Package constructor is getting hit 4201 times for us, but I don't see any cases where there are duplicates - each root looks like it gets one Package.

Oh, however as the build continues it gets hit with more roots, these ones are rewritten-packages/ with fingerprinted names. But I think that is after the speed savings this caching introduced for us

I'm not quite sure what the CI failures are here, a quick attempt didn't reproduce them locally.

To provide more color on this particular slowness, when we hit these realpathSync calls we're inside the recursive findActiveAddons logic inside partitionEngines:

Is it possible that it is safe to cache some of this work further up? We have lots of engines that have lots of addon dependencies in common, so I think effectively there's a lot of redundant work happening. And it just happens that the realpath use is the main expensive thing in that work.

Can you please test #1609 in your app as well to see what the build performance impact is?

I am hoping that PR makes a significant improvement, and also it might mean we don't need the new cache that's in this PR.

@ef4 #1609 seems to make a massive improvement to how much time our build spends in webpack, but I'm not sure if it cuts the number of hits I'm seeing to realpath, it still looks to be in the millions.